For signal correctness, try running the system tests on the Diamond network: https://github.com/DiamondLightSource/dodal?tab=readme-ov-file#testing-connectivity

connectivity check fails for this device AND panda1

will test on 30.07

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 94.44%. Comparing base (46132f0) to head (291050c).
Report is 2 commits behind head on main.

@@           Coverage Diff           @@
##             main     #672   +/-   ##
=======================================
  Coverage   94.43%   94.44%           
=======================================
  Files         113      113           
  Lines        4581     4588    +7     
=======================================
+ Hits         4326     4333    +7     
  Misses        255      255           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

not sure what is the desired behavior, which PVs do we want to expose?

the EDM screen shows:
X, Y, HDSO, VDSO, of the 2 latter each has a raw and 'real' variant.
There is an abscence of words known from other slits, such as x centre, or gap

@DiamondJoseph please advise

Let's ask the beamline scientist tomorrow, but I assume that we want all of them.
Let's also keep them as Motors, same as the existing Slits, if they're not being moved that's fine but let's keep the option open

still not right, need to talk to the scientists

@DiamondJoseph this fits the Hyperion model of 'the changes fit our model of the beamline', and it passes the tests, can we merge this now?

dodal connect i22
Attempting connection to i22 (using dodal.beamlines.i22)
16 devices connected :
        oav
        fswitch
        slits_6
        slits_5
        slits_4
        slits_3
        slits_2
        slits_1
        undulator
        hfm
        vfm
        it
        i0
        waxs
        synchrotron
        saxs

this was successful, ready to merge

class Slits(StandardReadable):
    def __init__(self, prefix: str, name: str = "") -> None:
        with self.add_children_as_readables():
            self.x_gap = Motor(prefix + "X:SIZE")
            self.y_gap = Motor(prefix + "Y:SIZE")
            self.x_centre = Motor(prefix + "X:CENTRE")
            self.y_centre = Motor(prefix + "Y:CENTRE")
        super().__init__(name)


class SpecialSlits(StandardReadable):
    def __init__(self, prefix: str, name: str = "") -> None:
        with self.add_children_as_readables():
            self.x = Motor(prefix + "X")
            self.y = Motor(prefix + "Y")
            self.x_gap = Motor(prefix + "HDSO")
            self.y_gap = Motor(prefix + "VDSO")
        super().__init__(name)

At which point we've got some very similar looking classes. It'd be nice if we could a. confirm that SpecialSlits.x is defining x centre, not e.g. x_min, and b. treat them all as some sort of generic slit with x_centre, x_gap, y_centre, y_gap

yes, it is centre. we can make both classes have the same properties but they do need to have different logic.

@DominicOram and @DiamondJoseph, how would you like this to be implemented?
the ways I see

• (default) keep 2 classes
• just 1 class with an override option for the channel names - that done either with a ternary inline logic or a big logic branch inside add_children_as_readables
• some interface that both classes implement that defines the same 4 properties

* just 1 class with an override option for the channel names (in the constructor with the 5/6 case as the default and the 1/6 case as the special override)

would be my preference.

My preference would be:

1. Create an alias at the EPICs layer so that the PVs are the same - we have done this for a set on i03
2. If we're short on time ask for the alias and do the override of channel names

closing as this will be solved at the epics layer